Skip to content

Conversation

@nflaig
Copy link
Member

@nflaig nflaig commented Nov 1, 2025

Adds proposer duties v2 endpoint to account for deterministic proposer lookahead ethereum/consensus-specs#4190 and return a different dependent_root based on current fork (pre/post fulu).

NOTE: this endpoint is not part of fulu release and is only required for gloas, it cannot be relied upon before that as clients might not have implemented it.

@rolfyone
Copy link
Contributor

rolfyone commented Nov 2, 2025

can we clarify this? When is it required from? clearly its missing fulu... is that ok?

@michaelsproul
Copy link
Contributor

Will be required from Gloas, so that we can then deprecate v1.

@nflaig nflaig added the Gloas api's needed in Gloas fork. label Nov 2, 2025
@rolfyone
Copy link
Contributor

rolfyone commented Nov 2, 2025

Will be required from Gloas, so that we can then deprecate v1.

ok great - thats perfect. We can get it done earlier but it's missed our fulu release is all and it does concern me when i can't implement a 'required' endpoint...

rolfyone
rolfyone previously approved these changes Nov 2, 2025
Copy link
Contributor

@rolfyone rolfyone left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm just a nit because we're tagging as required, we should put in description when it's required from to be clear.

nflaig added a commit to ChainSafe/lodestar that referenced this pull request Nov 4, 2025
Adds proposer duties v2 endpoint which works the same as v1 but uses
previous epoch to determine dependent root to account for deterministic
proposer lookahead changes in fulu.

ethereum/beacon-APIs#563
@nflaig nflaig requested a review from rolfyone November 24, 2025 16:27
@rolfyone
Copy link
Contributor

now that i've actually implemented the dependent root change for fulu for teku, i do wonder if a new endpoint is correct or if we just need a better understanding of why this dependent root is different in fulu @michaelsproul... maybe the better option is understanding that for the block proposals dependent root either 1 or 2 epochs prior are equally valid, and its just differing opinion on implementations....

I think that we'd probably need to 'hack' dependent root in teku now that it is computing proposer duties using lookahead...

@nflaig
Copy link
Member Author

nflaig commented Dec 5, 2025

the block proposals dependent root either 1 or 2 epochs prior are equally valid

From a validator client perspective it doesn't make much of a difference but it avoids reorging duties in some edge cases. If I remember correctly the demand came from out of protocol (Lido?) because they need consistent responses from each CL client so it would be good if we can come to consensus what dependent root to return and imo current behavior of v1 endpoint is incorrect post-fulu.

Is the problem in teku just that you need to handle both cases (pre/post fulu)?

@rolfyone
Copy link
Contributor

rolfyone commented Dec 5, 2025

Is the problem in teku just that you need to handle both cases (pre/post fulu)?

i can lie like lighthouse is going to in post fulu world, its just not the acutal dependent root so im appreciating what sprouls point was now that i see it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Gloas api's needed in Gloas fork.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants